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L REAL PARTY IN INTEREST 

The real party in interest of Application Serial No. 09/817,322 is the Assignee of 

record: 

Siemens Medical Solutions Health Services Corporation 
51 Valley Stream Parkway 
Malvern, PA 19355-1406 

IL RELATED APPEALS AND INTERFERENCES 

There is currently a co-pending appeal in related application serial number 
09/817,324 wherein a Notice of Appeal has been filed on May 1 1, 2006. An Appeal Brief 
has been filed on June 5, 2006, The present application and the application of the co- 
pending appeal claim priority from the same Provisional Application Serial No. 60/261,148. 

A Notice of Appeal was filed in application serial number 09/817,320 on August 15, 

2005 and as a result, prosecution was re-opened by Non-Final Office Action on March 9 S 

2006 followed by a subsequent Notice of Appeal on April 12, 2006. A Request for 
Continued Examination with a Preliminary Amendment was filed in response thereto on 
June 12, 2006. 

A Notice of Appeal was filed in application serial number 09/81.7,323 on July 7, 
2005 and as a result, prosecution was re-opened by Non-Final Office Action on March 9, 
2006. A response to the Non Final Office Action was filed on June 7, 2006. 

The present application and application serial numbers 09/817,323 and 09/817,320 
claim priority from the same provisional application serial number 60/261 J 48. 
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llh STATUS OF THE CLAIMS 

Claims 1 - 24 are rejected and the rejection of claims 1 - 24 are appealed. 



IV, STATUS OF AMENDMENTS 

All amendments were entered and are reflected in the claims included in Appendix I 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

Independent claim 1 provides a system for use in a first application, concurrently 
operating together with a plurality of network compatible applications (page 1, lines 34-36; 
Figure 2, 200, 230, 250). An entitlement processor enables user access to a first application 
of a plurality of concurrently operating applications in response to validation of user 
identification information (page 2, lines 4-6; Figure 2, 220, 200). A communication 
processor is employed by the first application of the plurality of concurrently operating 
applications for intermittently communicating an activity indication to a managing 
application within a timeout window (page 2, lines 6-8; Figure 2, 222, 224, 250). The 
activity indication is generated in response to user action and is communicated sufficiently 
often to prevent, an inactivity timeout of the first application being initiated during normal 
operation of the first application by the managing application in response to the timeout 
window being exceeded (page 2, lines 8-9; Figure 2, 200, 230, 250). 

Dependent claim 2 includes the features of independent claim 1 along with the 
addidonal feature thai the intermittently communicated activity indication prevents an 
inactivity timeout of the plurality of concurrently operating applications of a particular user 
initiated session (page 5, lines 24-27; Figure 2, 200, 230, 250). 
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Dependent claim 3 includes the features of independent claim 1 along with the 
additional feature that the communication processor stores a plurality of activity indications 
and sends the plurality of activity indications as a batch to the managing application (page 
15, lines 17-22; FIG 11). 

Dependent claim 4 includes the features of independent claim 1 along with the 
additional feature that the normal operation comprises application operation exclusive of 
abnormal operation comprising an application failure condition (page 15, lines 12-16; 
Figure 2, 230, 247, 250; Figure II, 460). The user action comprises at least one of, (a) 
keyboard activity, (b) mouse activity, (c) other data entry device activity and (d) another 
user initiated PC application operation activity (page 15, lines 19-22). 

Dependent claim 5 includes the features of independent claim 1 along with the 
additional feature that the first application and the managing application reside in the same 
PC (page 4, lines 7-9; Figure 2, 220, 230). The activity indication notifies the managing 
application of activity by the first application and includes one or more of, (a) a session 
identifier for identifying a particular user initiated session (page 5, lines 28-29; Figure 2, 
200, 230, 250), (b) a URL to be contacted if the activity notification is not successful (page 
7, lines 21-26; Figure 2, 200), (c) an identification of a type of event preventing the activity 
notification from being successful (page 7, lines 7-9; Figure 5, 500, 503, 505, 507, 513, 
517). 

Dependent claim 6 includes the features of independent claim I along with the 
additional feature that the communication processor intermittently communicates activity 
indications to the managing application using a plurality of different commands including 
an activity notification command and a command involving at least one of, (a) determining 
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a user operation session identifier from said managing application and (b) sending a URL 
to said managing application (page 14, lines 3-8; Figure 9, 900, 903, 91 1, 913, 917). 

Dependent claim 7 includes the features of independent claim 1 along with the 
additional feature that the communication processor communicates to the managing 
application a request to receive an activity indication associated with the first application 
and maintained by the managing application (page 15, lines 24-25; Figure 2, 200, 250). 
The activity indication indicates lime since the last activity update (page 16, lines 2-5; 
Figure 2, 233, 250, 280). 

Dependent claim 8 includes the features of independent claim 1 along with the 
additional feature that individual applications of the plurality of concurrently operating 
applications independently intermittently communicate an activity indication to the 
managing application (page 2, lines 6-7; Figure 2, 222, 250, 224). The communication 
processor communicates with a browser application providing a user interface display 
permitting user entry of identification information for validation by the entitlement 
processor (page 17, lines 1 1-13; Figure 3; 310, 313, 315), 

Dependent claim 9 includes the features of independent claim 1 along with the 
additional feature that the communication processor communicates a time-out threshold 
value comprising the timeout window to the managing application (page 2, lines 6-9; 
Figure 2, 200, 233, 250). 

Independent claim 10 provides a system for use by a managing application 
supporting concurrent operation of a plurality of Internet compatible applications (page L 
lines 34-36; Figure 2, 200, 230, 250). An input processor intermittently receives activity 
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indications from a plurality of concurrently operating applications (page 2, lines 10-12; 
Figure 2, 200, 230). An individual activity indication is generated in response to user 
action (page 15, lines 3-4; Figure 2, 230, 247, 250), In response to the received activity 
indications, an activity monitor updates individual activity status indicators, corresponding 
to the plurality of concurrently operating applications (page 15, lines 22-23; Figure 2, 250, 
280). A comparator compares individual activity status indicators with corresponding 
time-out threshold values to identify an application time-out event indicated by a status 
indicator exceeding the time-out threshold and occurring during normal operation of an 
application (page 1.5, lines 12-16; Figure 2, 230, 250, 247, 237; Figure 11, 460, 463). A 
communication processor communicates notice of the application time-out event to one of 
the plurality of concurrently operating applications (page 15, lines 28-30; Figure 2, 250). 

Dependent claim 1 1 includes the features of independent claim 3 0, along with the 
additional feature that the activity indications received by the input processor are provided 
in response to a user action (page 15, lines 12-16; Figure 2, 230, 250, 247; Figure 1 1, 460), 
The user action comprises at least one of, (a) keyboard activity, (b) mouse activity, (c) 
other data entry device and (d) another user initiated PC application operation activity 
(page 15, lines 19-22). 

Dependent claim 12 includes the features of independent claim 10 along with the 
additional feature that an activity status indicator comprises a time indication identifying 
when activity of a particular application was last reported (page 16, lines 2-5; Figure 2, 
250, 233, 280). The time-out threshold comprises a predetermined time duration (page 16, 
lines 14-17; Figure 12, 577, 583, 589). The managing application determines the particular 
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application to be inactive if the time indication exceeds the time-out threshold (page 17, 
lines 4-5; Figure 2, 250). 

Dependent claim 13 includes the features of independent claim 10 along with the 
additional feature that the input processor receives activity indications from a plurality of 
different commands including an activity notification command and a command involving 
at least one of, (a) determining a user operation session identifier from said managing 
application and (b) sending a URL to said managing application (page 1.4, lines 3-8; Figure 
9, 900, 903,91 1,913,917). 

Dependent claim 14 includes the features of independent claim 10 along with the 
additional feature that the communication processor communicates notice of the application 
time-out event to applications of the plurality of concurrently operating applications that have 
previously requested a notification of session termination (page 16, lines 5-7; Figure 2, 
250). 

Dependent claim 15 includes the features of independent claim 10 along with the 
additional feature that the communication processor communicates notice of the application 
time-out event in response to at. least one condition of, (a) a received command requesting 
notification and (b) a received communication from an application session having 
previously produced a time-out event and (c) automatically upon generation of the time-out 
event (page 14, lines 31 to page 15, line 6; Figure 2, 21 L 230, 247, 250, 283), 

Dependent claim 17 includes the features of independent claim 10 along with the 
additional feature that the corresponding time-out threshold values comprise a common 
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timeout period for the plurality of concurrently operating applications (page 7, lines 17-18; 
Figure 5, 520; Figure 2, 200, 250), 



Independent claim 19 provides a system supporting concurrent operation of a 
plurality of Internet compatible applications (page 1, lines 34-36; Figure 2, 200, 230, 250). 
A browser application provides a user interface display permitting user entry of 
identification information and commands for a plurality of Internet compatible applications 
(Figure 3; 310, 31.3, 315), A managing application receives activity indications from a 
plurality of concurrently operating applications (page 2 5 lines 10-12; Figure 2, 200, 230). 
An individual activity indication is generated in response to user action (page 3 5, lines 3-4; 
Figure 2, 230, 247, 250). The plurality of concurrently operating applications is initiated 
by user commands via the browser user interface (Figure 3; 313, 315), The received 
activity indications are provided by individual applications sufficiently frequently to 
prevent an inactivity timeout of the individual applications and during normal operation of 
an individual application (page 2 T lines 8-9; Figure 2, 200, 233, 250). 

Dependent claim 20 includes the features of independent claim 19 along with the 
additional feature that the activity indication notification includes one or more of, (a) an 
identification of a particular user initiated session (page 5, lines 28-29; Figure 2, 200, 230, 
250) (b) a URL to be contacted if said activity notification is not successful (page 7, lines 
21-26; Figure 2, 200), (c) an identification of a type of event preventing said activity 
notification from being successful (page 7, lines 7-9; Figure 5, 500, 503, 505, 507, 513, 
517). 



Independent claim. 22 provides a method in a system supporting concurrent 
operation of a plurality of network compatible applications (page 1, lines 34-36; Figure 2, 
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200, 230, 250). Activity indications are intermittently received from a plurality of 
concurrently operating applications (page 2, lines 10-12; Figure 2, 200, 230). An 
individual activity indication is generated in response to user action (page 15, Sines 3-4; 
Figure 2, 230, 247, 250). Individual activity status indicators, corresponding to said 
plurality of concurrently operating applications, are updated in response to said received 
activity indications (page 1.5, lines 22-23; Figure 2, 250, 280). Individual activity status 
indicators are compared with corresponding time-out threshold values to identify an 
application time-out event indicated by a status indicator exceeding the time-out threshold 
and occurring during normal operation of an application (page .15, lines 12-16; Figure 2, 
230, 250, 247, 237; Figure 11, 460, 463). Notice of the application time-out event is 
communicated to one of the plurality of concurrently operating applications (page 15, lines 
28-30; Figure 2, 250), 

Independent claim 23 provides a method employed by a first application operating 
in a system supporting concurrent operation of a plurality of network compatible 
applications (page 1, lines 34-36; Figure 2, 200, 230, 250). User access to a first 
application of a plurality of concurrently operating applications is enabled in response to 
validation of user identification information (page 17, lines 1 1-13; Figure 3, 310, 313, 315), 
Intermittent communication by the first application of an activity indication to a managing 
application within a timeout window is supported (page 2, lines 7-9; Figure 2, 200. 233, 
250). The activity indication notification is generated in response to user action and is 
communicated sufficiently often to prevent an inactivity timeout of the first application 
being initiated during normal operation of the first application by the managing application 
in response to the timeout window being exceeded (page 2, lines 7-9; Figure 2, 200, 233, 
250). 
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Independent claim 24 provides a method in a system supporting concurrent 
operation of a plurality of network compatible applications (page 1, lines 34-36; Figure 2, 
200, 230, 250). Activity indications are intermittently received from a plurality of 
concurrently operating applications of a particular operating session of a user (page 2, lines 
10-12; Figure 2, 200, 230). An individual activity indication is generated in response to 
user action (page 15, lines 3-4; Figure 2, 230, 247, 250). A single activity status indicator 
associated with the plurality of concurrently operating applications of the particular 
operating session is updated in response to the received activity indications (page 15, lines 
22-23; Figure 2, 250, 280). The single activity status indicator is compared with a time-out 
threshold value to identify a time-out event indicated by a status indicator exceeding said 
time-out threshold and occurring during normal operation of an application (page 15, lines 
12-16; Figure 2, 230, 237, 247, 250; Figure 11, 460, 463). The plurality of concurrently 
operating applications is re-initialized in response to the comparison (page 16, line 35 to 
page 1.7, line 1; Figure 2, 230, 250, 259, 215, 237). 

¥L GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Claims 1-24 are rejected under 35 U.S.C. 103(a) as being unpatentable over Cohen 
et al. (U.S. Patent No. 6,178,51 1) in view of Tran (U.S. Patent No. 6,505,238). 

VH. ARGUMENT 

Cohen when taken alone or in combination with Tran does not make the present 
claimed invention unpatentable. Thus, reversal of the Final Rejection (hereinafter termed 
"rejection") of claims 1-24 under 35 U.S.C. § 103(a) is respectfully requested. 
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Additionally the Examiner identified that the cross reference related to the 
application cited in the specification must be updated. Applicant respectfully submits that 
this will be corrected upon positive disposition of the appeal. 

Overview of the Cited References 
Cohen provides a single sign-on (SSO) mechanism enabling a given user to access a 
target application on a target resource in a distributed computer enterprise. One or more 
configuration directives each identifying a given logon process and any associated methods 
required to access the target application on the target resource are stored in a preferably 
global-accessible database (CEVf), For each of a set of users, a preferably global-accessible 
database (PKM) stores user-specific and application-specific information enabling the user 
to access and logon to one or more target resources. During a particular session, a logon 
coordinator (LC) mechanism coordinates given user information with the configuration 
directive to enable the given user to perform a given action with respect to the target 
application without specifying the given logon process and the application-specific 
information (see Abstract). 

Tran provides a method for allowing remote login to a user's personal workstation. 
The workstation is a client terminal connected to a server within a network. The method 
comprises the steps of searching, from a remote location, for a login web page of the 
network via a web browser and entering a series of login credential information into a 
particular login request area on the web page. In response to correctly entering the login 
credential information into the login request area, the user is provided with a graphical user 
interface (GUI) of the particular user's network terminal and full access to the personal 
network information such as software applications stored in the memory of the client 
terminal, (i.e. simulating the user's client terminal GUI and providing full access to locally 
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stored software and functional elements of the user's client terminal). In a preferred 
embodiment, the login credential information includes the server site, the user identification, 
and the user's security password. The search for the particular web page and user's 
workstation using the login credential information is managed by a directory access protocol 
(see Abstract), 

Rejection of Claims 1-24 under 35 USC 103(a) 
over Cohen et ah (U.S. Patent No. 6,178,511) in view of Tran 
OJ.S. Patent No, 6,505.238) 

Reversal, of the rejection of claims 1-24 under 35 UL3.C. 103(a) as being 
unpatentable over U.S, Patent 6,178,511 issued to Cohen et aL in view of U.S. Patent 
6,505,238 issued to Tran is respectfully requested because the rejection makes crucial 
errors in interpreting the cited references. The rejection erroneously states that claims 1-24 
are made unpatentable by Cohen in view of Tran. 

In rejecting claims under 35 LLS.C § 103, it is incumbent upon the examiner to 
establish a factual basis to support the legal conclusion of obviousness. In re Fine, 837 F.2d 
1071, 5 USPQ2d 1596, 1598 (Fed.Cin 1988). In so doing, the Examiner is expected to 
make the factual determinations set forth in Graham v. John Deere Co., 383 U.S. 1, 17, 148 
USPQ 459, 467 (CCPA 1966), and to provide a reason why one having ordinary skill in the 
pertinent art would have been led to modify the prior art or to combine prior art references 
to arrive at ihe claimed invention. Such reason must stem from some teaching, suggestion, 
or implication in the prior art as a whole or knowledge generally available to one having 
ordinary skill in the art.. Uni royal, Inc. v\ RudkmAViley Corp., 837 R2d 1044, 1051, 5 
USPQ2d 1434, 1438 (Fed-Cin 1988), cert, denied, 488 U.S. 825 (1988); Ashland Oil Inc. v. 
Delta Resins & Refractories, Inc., 776 E2d 28, 293, 227 USPQ 657, 664 (Fed.Cir. 1985), 
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cert, denied, 475 U.S. 10.17 (1986); ACS Hasp. Sys., Inc. v. Montefiore Hasp., 732 R2d 
1572, 1577, 221 USPQ 929, 933 (Fed.Cir. 1984). These showings by the Examiner are an 
essential part of complying with the burden of presenting a prima facie case of obviousness. 
In re Oetiker, 977 K2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed,Cir, 1992). 



CLAIM 1 

The system of claim 1 includes "a communication processor employed by said first 
application of said plurality of concurrently operating applications for intermittently 
communicating an activity indication to a managing application within a timeout window/' 
The "activity indication" is "communicated sufficiently often to prevent an inactivity 
timeout of said first application being initiated during normal operation of said first 
application by said managing application in response to said timeout window being 
exceeded." Cohen (with Tran) does not suggest such features. As recognized in the 
Rejection page 3, Cohen does not teach a system able to prevent "an inactivity timeout of 
said first application being initiated during normal operation of said first application/' 
Applicant respectfully submits that the Examiner is incorrect in maintaining on page 8 of 
the Rejection that Tran (with Cohen) teaches a system able to "prevent an inactivity 
timeout of said first application being initiated during normal operation of said first 
application" by a "managing application" in response to a "timeout window being 
exceeded/' 

Tran, in column 9 lines 14, 23 and lines 42-62 relied on in the Rejection, describes a 
system for searching "its database to find the web page of the network server* or a 
"network's general web site." In the "illustrative example, for IBM organization, LDAP 
begins the search for the userid at the first IBM location in the database (Austin) and 
continues sequentially through the different IBM locations„Jf one of the locations is 
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unavailable (for example, the network server is down), the process continues to the next 
location after a timeout condition is reached. For illustrative purposes, this timeout 
condition may occur after 5 seconds or after 5 tries to access the server or network at a 
location is unsuccessful The timeout condition is used to prevent the search from stalling 
at an unaccessible location. A check is made for the occurrence of a timeout so that the 
process continues smoothly" (Tran column 9 lines 43-57). 

Contrary to the assertions made in the Office Action and the response to 
Applicant's arguments, the Tran (with Cohen) timeout function is fundamentally different 
to the claimed system and comprises a different function employed in a different manner to 
achieve a different result that addresses a different problem, The re-try or timeout system of 
Tran, relied on in the Rejection, addresses an abnormal condition, specifically, "this 
timeout condition may occur after 5 seconds or after 5 tries to access the server or network 
at a location is unsuccessful" to "prevent the search from stalling at an unaccessible 
location" (Tran column 9 lines 52-56) and is not related to "normal operation" of a "first 
application" at alL In the Tran system, an LDAP compatible application searches for a 
"web page of the network server' or a "network's general web site" ("LDAP begins the 
search for the userid at the first IBM location in the database (Austin) and continues 
sequentially through the different IBM locations... timeout condition may occur after 5 
seconds or after 5 tries" by the LDAP application "to access the server or network" (Tran 
column 9 lines 45-55)). Consequently, the timeout condition occurs in response to a 
periodic clock measurement i.e., of "5 seconds" or a re-try count "after 5 tries" by the 
LDAP application and independently of user initiated activity and is NOT an indicator 
of "activity" but merely that a search by an LDAP application has timed out due to an 
abnormal (e.g. an "unaccessible" location) condition. 
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The timeout condition in Tran is generated even when there is no user activity in the 
LDAP application. Therefore, the Cohen with Tran system does not suggest a "first 
application" of a "plurality of concurrently operating applications for intermittently 
communicating an activity indication" generated "in response to user action" to "a 
managing application" to "prevent an inactivity timeout" of the "first application being 
initiated during normal operation of said first application". Further, Tran (with Cohen) 
fails to show or suggest generation of an "activity indication" in response "to user action 
and being communicated sufficiently often to prevent an inactivity timeout of said first 
application being initiated during normal operation of said first application by said 
managing application in response to said timeout window being exceeded," Also, since the 
Tran (with Cohen) timeout condition is generated by an application independent of user 
action, the Cohen with Tran system is incapable of "monitoring and controlling a duration 
of a user session," in contrast to the claimed arrangement. 

The re-try or timeout system of Tran (with Cohen), relied on in the Rejection, 
addresses an abnormal condition, specifically, "this timeout condition may occur after 5 
seconds or after 5 tries to access the server or network at a location is unsuccessful" to 
"prevent the search from stalling at an unaccessible location" (Tran column 9 lines 52-56) 
and is not related to "normal operation" of a "first application." In contrast, in the 
claimed arrangement, a "first application" of a "plurality of concurrently operating 
applications" intermittently communicates "an activity indication" generated "in response 
to user action" to "prevent an inactivity timeout" of the "first application being initiated" 
during "normal operation of said first application" in response to the "timeout window 
being exceeded." The communicated "activity indication" is used to identify a "normal" 
condition of user inactivity in employing an application, whereas the Cohen with Tran 
system identifies a purely abnormal condition comprising a failure circumstance. Further, 
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incorporating the re-try timeout mechanism of Tran into the Single Sign On system of 
Cohen, as suggested in the Rejection, results in a system for detecting an abnormal 
condition during user Logon and initiates a timeout "after 5 seconds or after 5 tries" for 
example, when it is "unsuccessful" in accessing a server or network, and thus can only 
detect a failure condition. This combined system is incapable of preventing "inactivity 
timeout" of a "first application being initiated" in response to user inactivity. 
Additionally, Applicant further respectfully submits that there is no reason or motivation to 
combine the systems disclosed by Cohen and Trail. Cohen and Tran are mutually 
incompatible systems, as Tran provides no 35 USC 112 enabling disclosure of single-sign 
on mechanism, as required for proper operation of the Cohen system. Thus Cohen and Tran 
would produce an inoperable system as neither discloses nor suggests the claimed 
arrangement. 

The re-try timeout mechanism of Cohen with Tran addresses the problem of 
managing an abnormal condition and detecting a failure condition during user Logon by 
initiating a timeout condition "after 5 seconds or after 5 tries" that are "unsuccessful" in 
accessing a server or network, for example, (Tran column 9 lines 52-56) and does not 
recognize, contemplate or address the problems of application inactivity management 
under "normal" operating conditions. Therefore, Cohen with Tran provides no problem 
recognition, motivation, or other reason for incorporating the claimed features. 
Consequently withdrawal of the Rejection of claim 1 under 35 USC 103(a) is respectfully 
requested. 

CLAIM 2 

Dependent claim 2 is considered to be patentable based on its dependence on claim 
L Claim 2 is also considered to be patentable because Cohen with Tran does not show or 
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suggest use of an "intermittently communicated activity indication" that "prevents an 
inactivity timeout of said plurality of concurrently operating applications of a particular 
user initiated session" (of potentially multiple sessions operating on the computer). 

As previously explained in connection with claim 1, Cohen with Tran fails to teach 
or suggest "a managing application" for initiating "an inactivity timeout" of a "plurality of 
concurrently operating applications of a particular user initiated session" in response to 
lack of "user action". As described in column 9, lines 43-56 of Tran, Tran (with Cohen) 
timeout operates based on the system being unable to access the server or network after a 
predetermined time or number of tries. The system's inability to access the server is not in 
response to 'lack of "user action" as in the present claimed invention. Thus, the Cohen 
with Tran timeout operates independently of an inactivity indication generated due to lack 
of "user action", Consequently withdrawal of the Rejection of claim 2 under 35 USC 
103(a) is respectfully requested. 

CLAIM 3 

Dependent claim 3 is considered to be patentable based on its dependence on claim 
I. Claim 3 is also considered to be patentable because Cohen with Tran does not show or 
suggest use of a "communication processor" that "stores a plurality of activity indications 
and sends said plurality of activity indications as a batch to said managing application" as 
recited in the present claimed invention. 

Contrary to the Rejection statement on page 4, Cohen (with Tran) in column 6 lines 
38-59 does not mention a "batch" mode at all and neither reference alone or together 
suggests generating an "activity indication" in response "to user action and being 
communicated sufficiently often to prevent an inactivity timeout of said first application 
being initiated during normal operation". Rather, this passage of Cohen merely describes a 
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mechanism for allowing different passwords for different target systems and applications 
and only requiring the user to remember one password to log into the mechanism. Neither 
reference alone or together provides a 35 USC 112 compliant enabling description or 
suggestion of such a "batch" mode. Consequently withdrawal of the Rejection of claim 3 
under 35 USC 103(a) is respectfully requested. 

CLAIM 4 

Dependent claim 4 is considered to be patentable based on its dependence on claim 
1 . Claim 4 is also considered to be patentable because Cohen with Tran does not show or 
suggest "said normal operation comprises application operation exclusive of abnormal 
operation comprising an application failure condition and said user action comprises at 
least one of, (a) keyboard activity, (b) mouse activity, (c) other data entry device activity 
and (d) another user initiated PC application operation activity" as recited in the present 
claimed invention. As previously explained, the Tran (with Cohen) system is responsive to 
an abnormal condition, specifically, "this timeout condition may occur after 5 seconds or 
after 5 tries to access the server or network at a location is unsuccessful" to "prevent the 
search from stalling at an unaccessible location" (Tran column 9 lines 52-56) and is not 
related to "normal operation" and is also independent of user action. Cohen in column 6 
and column 10 or elsewhere with Tran fails to suggest "intermittently" communicating an 
"activity indication to said managing application in response to a user action" at all. 
Rather, column 10, as cited in the Rejection, describes the interaction of the SSO with 
given application or sub-systems. Column 6, lines 8-18, cited in the Rejection, merely 
describes a user's local logon being authenticated to the authentication service that is 
integrated with the password storage service. Applicant respectfully submits that contrary 
to the assertions in the Rejection, these passages and elsewhere make absolutely no 
mention or even suggestion of "intermittently" communicating an "activity indication to 
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said managing application in response to a user action" at all. Consequently withdrawal of 
the Rejection of claim 4 under 35 USC 103(a) is respectfully requested. 



CLAIM 5 

Dependent claim 5 is considered to be patentable based on its dependence on claim 
1. Claim 5 is also considered to be patentable because Cohen with Tran does not show or 
suggest a system in which the "first application and said managing application reside in the 
same PC" and "said activity indication notifies said managing application of activity by 
said first application and includes one or more of, (a) a session identifier for identifying a 
particular user initiated session, (b) a URL to be contacted if said activity notification is not 
successful, (c) an identification of a type of event preventing said activity notification from 
being successful", Cohen (in column 5 line 30 to column 6 line 7 relied on) with Tran fails 
to suggest an "activity indication" that "notifies" a "managing application of activity by 
said first application and includes one or more of, (a) a session identifier for identifying a 
particular user initiated session, (b) a URL to be contacted if said activity notification is not 
successful, (c) an identification of a type of event preventing said activity notification from 
being successful". Rather, this passage merely describes the user-specific application data 
included in the personal key manager (PKM). Consequently withdrawal of the Rejection of 
claim 5 under 35 USC 103(a) is respectfully requested, 

CLAIM 6 

Dependent claim 6 is considered to be patentable based on its dependence on claim 
L Claim 6 is also considered to be patentable because Cohen (in column 5 line 30 to line 
40 relied on in the Rejection) with Tran does not show or suggest a system in which a 
"communication processor intermittently communicates activity indications to said 
managing application using a plurality of different commands including an activity 
notification command and a command involving at least one of, (a) determining a user 
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operation session identifier from said managing application and (b) sending a URL to said 
managing application" as recited in the present claimed invention. Rather, this passage 
describes the user-specific application data contained in the personal key manager, namely 
the target name, target type, domain/host/application name, user id, and key information. 
There is no mention or even suggestion in this passage, and elsewhere in Cohen (with Tran) 
of any "activity indications," nor is there any mention or suggestion of a "communication 
processor intermittently communicates activity indications to said managing application 
using a plurality of different commands including an activity notification command and a 
command involving at least one of, (a) determining a user operation session identifier from 
said managing application and (b) sending a URL to said managing application" as recited 
in the present claimed invention. Consequently withdrawal of the Rejection of claim 6 
under 35 USC 103(a) is respectfully requested. 

CLAIM 7 

Dependent claim 7 is considered to be patentable based on its dependence on claim 
1. Claim 7 is also considered to be patentable because Cohen with Tran does not show or 
suggest a system in which a "communication processor communicates to said managing 
application a request to receive an activity indication associated with said first application 
and maintained by said managing application, said activity indication indicating time since 
the last activity update". The Cohen with Tran re-try timeout mechanism is independent of 
user action since an LDAP application initiates a timeout condition "after 5 seconds or 
after 5 tries" that are "unsuccessful" in accessing a server or network, for example, (Tran 
column 9 lines 52-56) independently of user activity. Cohen with Tran fails to suggest a 
"communication processor' that "communicates to said managing application a request to 
receive an activity indication associated with said first application and maintained by said 
managing application, said activity indication indicating time since the last activity 
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update". Cohen with Tran fails to suggest use of a centralized "managing application" for 
activity management at all, does not contemplate such a feature and is incapable of user 
based activity management. Cohen in column 8 lines 45-67 relied on in the Rejection fails 
to suggest such features and merely describes the method to avoid target passwords from 
being revealed to a single sign on administrator (or others). Consequently withdrawal of the 
Rejection of claim 7 under 35 USC 103(a) is respectfully requested. 

CLAIM 8 

Dependent claim 8 is considered to be patentable based on its dependence on claim 
1. Claim 8 is also considered to be patentable because Cohen with Tran does not show or 
suggest a system in which "individual applications of said plurality of concurrently 
operating applications independently intermittently communicate an activity indication to 
said managing application and said communication processor communicates with a 
browser application providing a user interface display permitting user entry of 
identification information for validation by said entitlement processor*', Cohen in columns 
6 and 7 and Figure 5 relied on in the Rejection, with Tran, fails to suggest "individual 
applications of said plurality of concurrently operating applications" that "independently 
intermittently communicate an activity indication to said managing application". Cohen 
with Tran also fails to suggest use of a centralized "managing application" for activity 
management at all. Consequently withdrawal of the Rejection of claim 8 under 35 USC 
103(a) is respectfully requested. 

CLAIM 9 

Dependent claim 9 is considered to be patentable based on its dependence on claim 
t Claim 9 is also considered to be patentable because Cohen with Tran does not show or 
suggest a system in which "said communication processor communicates a time-out 
threshold value comprising said timeout window to said managing application". Cohen in 
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column II, with Tran, fails to suggest a "communication processor" that "communicates a 
time-out threshold value comprising said timeout window to said managing application" 
for user responsive activity management. Consequently withdrawal of the Rejection of 
claim 9 under 35 USC 103(a) is respectfully requested. 



CLAIMS 10. 16 and 18 
Independent claim 10 recites a system for "use by a managing application 

supporting concurrent operation of a plurality of Internet compatible applications" 

comprising "an input processor for intermittently receiving activity indications from a 

plurality of concurrently operating applications, an individual activity indication being 

generated in response to user action; an activity monitor for updating individual activity 

status indicators, corresponding to said plurality of concurrently operating applications, in 

response to said received activity indications; a comparator for comparing individual 

activity status indicators with corresponding time-out threshold values to identify an 

application time-out event indicated by a status indicator exceeding said time-out threshold 

and occurring during normal operation of an application; and a communication processor 

for communicating notice of said application time-out event to one of said plurality of 

concurrently operating applications," These features are not shown or suggested in Cohen 

with Tran. Independent claim 10 is considered to be patentable for reasons given in 

connection with claim I and other preceding claims. 

Claim 10 is also considered to be patentable because Cohen with Tran does not 
show or suggest a system used "by a managing application" involving 'Intermittently 
receiving activity indications from a plurality of concurrently operating applications, an 
individual activity indication being generated in response to user action" and including an 
"activity monitor for updating individual activity status indicators, corresponding to said 
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plurality of concurrently operating applications, in response to said received activity 
indications", Cohen in column 8 and Figure 5 relied on in the Rejection, with Tran, fails to 
suggest a system used "by a managing application" involving "intermittently receiving 
activity indications from a plurality of concurrently operating applications" and "an 
individual activity indication being generated in response to user action" and including an 
"activity monitor for updating individual activity status indicators, corresponding to said 
plurality of concurrently operating applications, in response to said received activity 
indications". Cohen with Tran fails to suggest "a comparator for comparing individual" 
user responsive "activity status indicators with corresponding time-out threshold values to 
identify an application time-out event indicated by a status indicator exceeding said time- 
out threshold and occurring during normal operation of an application; and a 
communication processor for communicating notice of said application time-out event to 
one of said plurality of concurrently operating applications". Rather, Figure 5 of Cohen, 
relied on in the rejection, merely describes a screen displaying the systems/applications 
(targets) the user is able to logon to and the status of the logon process, namely whether the 
user is logged in to the target or not. There is no indication or even suggestion of activity 
status indicators, let alone "activity status indicators with corresponding time-out 
threshold values to identify an application time-out event indicated by a status indicator 
exceeding said time-out threshold and occurring during normal operation of an 
application; and a communication processor for communicating notice of said application 
time-out event to one of said plurality of concurrently operating applications" as recited in 
the present claimed invention. 

Contrary to the assertions in the rejection, Column 8, lines 45-62 of Cohen neither 
discloses nor suggests "an activity monitor for updating individual activity status 
indicators, corresponding to said plurality of concurrently operating applications, in 
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response to said received activity indications," as recited in the present claimed invention. 
Rather, this passage of Cohen (with Tran) merely describes avoiding ^target passwords 
being revealed to SSO administrators (or others)" by encrypting the password field with a 
master key. This makes absolutely no mention or even suggestion of "updating 
individual activity status indicators, corresponding to said plurality of concurrently 
operating applications, in response to said received activity indications" as recited in the 
present claimed invention. Further, Cohen is concerned with providing a mechanism for 
allowing different passwords for different target systems and applications and only 
requiring the user to remember one password, to log into the mechanism. This is wholly 
unlike the present claimed invention which is concerned with monitoring the activity status 
of concurrently operating applications for time-out events. Cohen with Tran fails to 
disclose or suggest ''receiving activity indications. . .generated in response to user action," 
updating individual activity status indicators** and "comparing individual activity status 
indicators with corresponding time-out threshold values to identify an application time-out 
event indicated by a status indicator exceeding said time-out threshold and occurring during 
normal operation of an application." 

The re-try timeout mechanism of Cohen with Tran addresses the problem of 
managing an abnormal condition and detecting a failure condition during user Logon by 
initiating a timeout condition "after 5 seconds or after 5 tries" that are "unsuccessful*' in 
accessing a server or network, for example (Train column 9, lines 52-56) and does not 
recognize, contemplate or address the problems of application inactivity management 
under "normal" operating conditions. Therefore, Cohen with Tran provides no problem 
recognition, motivation, or other reason for incorporating the claimed features. 
Consequently withdrawal of the Rejection of claim 10 under 35 USC 103(a) is respectfully 
requested, 
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Dependent claims 16 and 18 are considered to be patentable based on their 
dependence on independent claim 10. Therefore, the arguments presented above with 
respect to claim 10 also apply to claims 16 and 18. Thus, withdrawal of the Rejection of 
claims 16 and 18 under 35 USC 1.03(a) is respectfully requested. 

CLAIM 1 1 

Dependent claim 11 is considered to be patentable based on its dependence on 
claim 1.0. Claim. 1 1 is also considered to be patentable because Cohen with Iran does not 
show or suggest "said activity indications received by said input processor are provided in 
response to user action and said user action comprises at least one of, (a) keyboard activity, 
(b) mouse activity, (c) other data entry device activity and (d) another user initiated PC 
application operation activity" as recited in the present claimed invention. As previously 
explained, the Tran (with Cohen) system is responsive to an abnormal condition, 
specifically, "this timeout condition may occur after 5 seconds or after 5 tries to access the 
server or network at a location is unsuccessful" to "prevent the search from stalling at an 
unaccessible location" (Tran column 9 lines 52-56) and is not related to "normal 
operation" and is also independent of user action, Cohen in column 6 and column 10 or 
elsewhere with Tran fails to suggest, communicating an "activity indication" "received by 
said input processor" "in response to a user action" at alb Rather, column 10, as cited in 
the Rejection, describes the interaction of the SSO with given application or sub-systems. 
Column 6, lines 8-18, cited in the Rejection, merely describes a user's local logon being 
authenticated to the authentication service that is integrated with the password storage 
service. Applicant respectfully submits that contrary to the assertions in the Rejection, 
these passages and elsewhere make absolutely no mention or even suggestion of 
communicating an "activity indication" "received by said input processor" "in response to 
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a user action" at alL Consequently withdrawal of the Rejection of claim 1 1 under 35 USC 
1.03(a) is respectfully requested. 



CLAIM 12 

Dependent claim 12 is considered to be patentable based on its dependence on 
claim 10. Claim 12 is also considered to be patentable because Cohen, in column 1 1 relied 
on or elsewhere, with Tran, does not show or suggest a system in which "an activity status 
indicator comprises a time indication identifying when activity of a particular application 
was last reported, and said time-out threshold comprises a predetermined time duration and 
said managing application determines said particular application to be inactive if said time 
indication exceeds said time-out threshold". Cohen with Tran fails to suggest 
communication of u an activity status indicator" that comprises a "time indication 
identifying when activity of a particular application was last reported, and said time-out 
threshold comprises a predetermined time duration and said managing application 
determines said particular application to be inactive if said time indication exceeds said 
time-out threshold". Column 1 1 5 beginning at line 35, merely describes having a minimum 
timeout and a maximum time out, indicating the amount of time the SSO should wait for a 
function to run. There is no mention or even suggestion of a "time indication identifying 
when activity of a particular application was last reported/' as recited in the present 
claimed invention. Cohen with Tran fail to suggest use of a centralized "managing 
application" for activity management, nor does Cohen with Tran describe any ability (or 
any suggestion) to process user responsive activity indications for individual executable 
applications at all. Consequently withdrawal of the Rejection of claim 12 under 35 USC 
103(a) is respectfully requested. 
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CLAIM 13 

Dependent claim 13 is considered to be patentable based on its dependence on 
claim 10. Claim 13 is also considered to be patentable because Cohen (in column 5 line 30 
to line 40 relied on in the Rejection) with Tran does not show or suggest a system in which 
the "input processor receives activity indications from a plurality of different commands 
including an activity notification command and a command involving at least one of, (a) 
determining a user operation session identifier from said managing application and (b) 
sending a URL to said managing application" as recited in the present claimed invention. 
Rather, this passage describes the user-specific application data contained in the personal 
key manager, namely the target name, target type, domain/host/application name, user id, 
and key information. There is no mention or even suggestion in this passage, and 
elsewhere in Cohen (with Tran) of any "activity indications " nor is there any mention or 
suggestion that an "input processor receives activity indications from a plurality of 
different commands including an activity notification command and a command involving 
at least one of, (a) determining a user operation session identifier from said managing 
application and (b) sending a URL to said managing application" as recited in the present 
claimed invention. Consequently withdrawal of the Rejection of claim 13 under 35 USC 
103(a) is respectfully requested. 

CLAIM 14 

Dependent claim 14 is considered to be patentable based on its dependence on 
claim 10. Claim 14 is also considered to be patentable because Cohen in column 6 lines 1-7 
relied or elsewhere, with Tran, does not show or suggest a feature combination in which 
"said communication processor communicates notice of said application time-out event to 
applications of said plurality of concurrently operating applications that: have previously 
requested a notification of session termination". Rather, this passage merely describes 
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application specific information, including interfaces needed to perform operations like 
logon and logoff, timeouts and retry counts and client specific information on how to locate 
the application interface code. Information including timeouts and retry counts is not 
equivalent to communicating "notice of said application time-out event to applications of 
said plurality of concurrently operating applications that have previously requested a 
notification of session termination". Cohen with Tran fail to suggest use of a centralized 
"managing application 7 ' for activity management, nor does Cohen with Tran describe any 
ability (or any suggestion) to process user responsive activity indications, for individual 
executable applications, at all. Consequently withdrawal of the Rejection of claim 14 under 
35 USC 103(a) is respectfully requested. 

CLAIM 15 

Dependent claim 15 is considered to be patentable based on its dependence on 
claim 10. Claim 15 is also considered to be patentable because Cohen with Tran does not 
show or suggest a system in which "said communication processor communicates notice of 
said application time-out event in response to at least one condition of, (a) a received 
command requesting notification and (b) a received communication from an application 
session having previously produced a time-out event and (c) automatically upon generation 
of said time-out event" as recited in the present claimed invention. Cohen in column 5 line 
59 to column 6 line? or elsewhere relied on, with Tran, fails to suggest communication of 
"notice of said application time-out event" resulting from user inactivity in "response to at 
least one condition of, (a) a received command requesting notification and (b) a received 
communication from an application session having previously produced a time-out event 
and (c) automatically upon generation of said time-out event" as recited in the present 
claimed invention. This passage of Cohen merely describes application specific 
information contained in a second database. The information includes the target type, the 
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default program., specific application information, program preferences and an interface 
directory. The program preferences including timeouts and retry counts is not equivalent to 
communicating "notice of said application time-out event" resulting from user inactivity in 
"response to at least one condition of, (a) a received command requesting notification and 
(b) a received communication from an application session having previously produced a 
time-out event and (c) automatically upon generation of said time-out event" as recited in 
the present claimed invention. Further, Cohen with Tran fails to suggest use of a centralized 
"managing application" for communication of "notice of said application time-out event" 
based on user inactivity in an application. Consequently withdrawal of the Rejection of 
claim 15 under 35 USC 103(a) is respectfully requested. 



CLAIM 1? 

Dependent claim 17 is considered to be patentable based on its dependence on 
claim 10. Claim 17 is also considered to be patentable because Cohen with Tran does not 
show or suggest a system in which "said corresponding time-out threshold values comprise 
a common timeout period for said plurality of concurrently operating applications". Cohen, 
in column 11, beginning on line 35, relied on in the rejection or elsewhere, with Tran, 
merely describes the inclusion of a minimum amount of time and a maximum amount of 
time the SSO should wait for a function to complete before returning and fails to suggest a 
system in which "said corresponding time-out threshold values" comprise a "common 
timeout period for said plurality of concurrently operating applications" for use in user 
responsive activity management. Cohen with Tran fails to suggest use of a centralized 
"managing application" employing "a common timeout period for said plurality of 
concurrently operating applications" for executable application activity management at all. 
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Consequently withdrawal of the Rejection of claim 17 under 35 USC 103(a) is respectfully 
requested. 



CLAIMS 19 and 21 

Independent claim 19 recites a system "supporting concurrent operation of a 
plurality of Internet compatible applications comprising "a browser application providing a 
user interface display permitting user entry of identification information and commands for 
a plurality of Internet compatible applications; and a managing application for receiving 
activity indications from a plurality of concurrently operating applications, an individual 
activity indication being generated in response to user action, said plurality of concurrently 
operating applications being initiated by user commands via said browser user interface, 
said received activity indications being provided by individual applications sufficiently 
frequently to prevent an inactivity timeout of said individual applications and during 
normal operation of an individual application". Claim 19 is considered to be patentable 
for reasons given in connection with claims 1 , 4 and 1(1 

The Tran (with Cohen) timeout function is fundamentally different to the claimed 
system and comprises a different function employed in a different manner to achieve a 
different result that addresses a different problem. The re-try or timeout system of Tran, 
relied on in. the Rejection, addresses an abnormal condition, specifically, "this timeout 
condition may occur after 5 seconds or after 5 tries to access the server or network at a 
location is unsuccessful" to "prevent the search from stalling at an unaccessible location" 
(Tran column 9 lines 52-56) and is not related to "normal operation" of an "individual 
application" at all. In the Tran system, an LDAP compatible application searches for a 
"web page of the network server" or a "network's general web site" ("LDAP begins the 
search for the userid at the first IBM location in the database (Austin) and continues 



30 



Serial No.: 09/817322 01P04776US01 

sequentially through the different IBM locations,.. timeout condition may occur after 5 
seconds or after 5 tries" by the LDAP application "to access the server or network" {Iran 
column 9 lines 45-55)). Consequently, the timeout condition occurs in response to a 
periodic clock measurement he., of "5 seconds" or a re™try count "after 5 tries" by the 
LDAP application and independently of user initiated activity and is NOT an indicator 
of "activity" but merely that a search by an LDAP application has timed out due to an 
abnormal (e g, an "unaccessible" location) condition. 

The timeout condition in Tran is generated even when there is no user activity in the 
LDAP application. Therefore, the Cohen with Tran system does not suggest an "individual 
activity application" of a "plurality of concurrently operating applications for receiving 
activity indication" generated 'in response to user action" to "a managing application" to 
"prevent an inactivity timeout" of the "individual application being initiated during normal 
operation of an individual application". Further, Tran (with Cohen) fails to show or 
suggest generation of an "activity indication" in response "to user commands ...and being 
provided by individual applications sufficiently frequently to prevent an inactivity timeout 
of said individual applications and during normal operation of an individual application." 
Also, since the Tran (with Cohen) timeout condition is generated by an application 
independent of user action, the Cohen with Tran system is incapable of "monitoring and 
controlling a duration of a user session," in contrast to the claimed arrangement. 

The re-try or timeout system of Tran (with Cohen), relied on in the Rejection, 
addresses an abnormal condition, specifically, "this timeout condition may occur after 5 
seconds or after 5 tries to access the server or network at a location is unsuccessful" to 
"prevent the search from stalling at an unaccessible location" (Tran column 9 lines 52-56) 
and is not related to "normal operation" of an "individual application." In contrast, in the 
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claimed arrangement, an "individual application" of a "plurality of concurrently operating 
applications" communicates "an activity indication" generated "in response to user 
action" to "prevent an inactivity timeout" of the "individual application" during "normal 
operation of an individual application." The communicated "activity indication" is used to 
identify a "normal" condition of user inactivity in employing an application, whereas the 
Cohen with Tran system identifies a purely abnormal condition comprising a failure 
circumstance. Further, incorporating the re-try timeout mechanism of Tran into the Single 
Sign On system of Cohen, as suggested in the Rejection, results in a system for detecting an 
abnormal condition during user Logon and initiates a timeout "after 5 seconds or after 5 
tries" for example, when it is "unsuccessful" in accessing a server or network, and thus can 
only detect a failure condition. This combined system is incapable of preventing 
"inactivity timeout" of an "individual application" in response to user inactivity. 

The re-try timeout mechanism of Cohen with Tran addresses the problem of 
managing an abnormal condition and detecting a failure condition during user Logon by 
initiating a timeout condition "after 5 seconds or after 5 tries" that are "unsuccessful" in 
accessing a server or network, for example, (Tran column 9 lines 52-56) and does not 
recognize, contemplate or address the problems of application inactivity management 
under "normal" operating conditions. Therefore, Cohen with Tran provides no problem 
recognition, motivation, or other reason for incorporating the claimed features. 

Further, contrary to the Rejection statement: on page 6 Cohen, in Column 6 line 19 
et seq. and Figure 5 does not mention an Internet compatible browser at all, but instead 
mentions a graphical user interface, which is not equivalent. Thus, Applicant respectfully 
submits that the assertion in the Rejection that "Cohen further teaches a browser 
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application" is incorrect. Consequently withdrawal of the Rejection of claim 19 under 35 
USC 103(a) is respectfully requested. 



Dependent claim 21 is considered to be patentable based on its dependence on 
independent claim 19, Therefore, the arguments presented above with respect to claim 19 
also apply to claim 2L Thus, withdrawal of the Rejection of claim 21 under 35 USC 
103(a) is respectfully requested. 



CLAIM 20 

Dependent claim 20 is considered to be patentable based on its dependence on 
claim 1. Claim 20 is also considered to be patentable because Cohen with Tran does not 
show or suggest a system in which "said activity indication notification includes one or 
more of, (a) an identification of a particular user initiated session, (b) a URL to be 
contacted if said activity notification is not successful, (c) an identification of a type of 
event preventing said activity notification from being successful". Cohen (in column 5 line 
30 to column 6 line 7 relied on) with Tran fails to suggest an "activity indication 
notification" that "includes one or more of, (a) an identification of a particular user initiated 
session, (b) a URL to be contacted if said activity notification is not successful, (c) an 
identification of a type of event preventing said activity notification from being 
successful". Rather, this passage merely describes the user-specific application data 
included in the personal key manager (PKM). Consequently withdrawal of the Rejection of 
claim 20 under 35 USC 103(a) is respectfully requested. 
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CLAIM 22 

Claim 22 recites a method used in "a system supporting concurrent 
operation of a plurality of network compatible applications" comprising the activities of 
"intermittently receiving activity indications from a plurality of concurrently operating 
applications, an individual activity indication being generated in response to user action; 
updated individual activity status indicators, corresponding to said plurality of concurrently 
operation applications, in response to said received activity indications; comparing 
individual activity status indicators with corresponding time-out threshold values to 
identify an application time-out event indicated by a status indicator exceeding said time- 
out threshold and occurring during normal operation of an application; and communicating 
notice of said application time-out event to one of said plurality of concurrently operation 
applications." These features are neither shown nor suggested by Cohen with Tram 

Cohen in column 8 and Figure 5 relied on in the Rejection, with Tran, fails to 
suggest a method involving 'Intermittently receiving activity indications from a plurality of 
concurrently operating applications" and "an individual activity indication being generated 
in response to user action" and including the activity of 'updating individual activity 
status indicators, corresponding to said plurality of concurrently operating applications, in 
response to said received activity indications". Cohen with Tran fails to suggest the activity 
of "comparing individual activity status indicators with corresponding time-out threshold 
values to identify an application time-out event indicated by a status indicator exceeding 
said time-out threshold and occurring during normal operation of an application; and 
communicating notice of said application time-out event to one of said plurality of 
concurrently operating applications". Rather, Figure 5 of Cohen, relied on in the rejection, 
merely describes a screen displaying the systems/applications (targets) the user is able to 
logon to and the status of the logon process, namely whether the user is logged in to the 
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target or not. There is no Indication or even suggestion of individual activity status 
Indicators, Jet alone "individual activity status indicators with corresponding time-out 
threshold values to identify an application time-out event indicated by a status indicator 
exceeding said time-out threshold and occurring during normal operation of an 
application; and communicating notice of said application time-out event to one of said 
plurality of concurrently operating applications" as recited in the present claimed invention. 

Contrary to the assertions in the rejection, Column 8, lines 45-62 of Cohen neither 
discloses nor suggests "updating individual activity status indicators, corresponding to said 
plurality of concurrently operating applications, in response to said received activity 
indications," as recited in the present claimed invention. Rather, this passage of Cohen 
(with Tran) merely describes avoiding "target passwords being revealed to SSO 
administrators (or others)" by encrypting the password field with a master key. This makes 
absolutely no mention or even suggestion of "updating individual activity status 
indicators, corresponding to said plurality of concurrently operating applications, in 
response to said received activity indications" as recited In the present claimed invention. 
Further, Cohen is concerned with providing a mechanism for allowing different passwords 
for different target systems and applications and only requiring the user to remember one 
password to log into the mechanism. This is wholly unlike the present claimed invention 
which is concerned with monitoring the activity status of concurrently operating 
applications for time-out events, Cohen with Tran fail to disclose or suggest "receiving 
activity indications.. .generated in response to user action," "updating individual activity 
status indicators" and "comparing individual activity status indicators with 
corresponding time-out threshold values to identify an application time-out event 
indicated by a status indicator exceeding said time-out threshold and occurring during 
normal operation of an application " 
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The re-try timeout mechanism of Cohen with Tran addresses the problem of 
managing an abnormal condition and detecting a failure condition during user Logon by 
initiating a timeout condition "after 5 seconds or after 5 tries" that are "unsuccessful" in 
accessing a server or network, for example (Train column 9, lines 52-56} and does not 
recognize, contemplate or address the problems of application inactivity management 
under "normal" operating conditions. Therefore, Cohen with Tran provides no problem 
recognition, motivation, or other reason for incorporating the claimed features, 
Consequently withdrawal of the Rejection of claim 22 under 35 USC 103(a) is respectfully 
requested. 

CLAIM 23 

The method of claim 23 is "employed by a first application operating in a system 
supporting concurrent operation of a plurality of network compatible applications" and 
includes the activities of "enabling user access to a first application of a plurality of 
concurrently operating applications in response to validation of user identification 
information." The "activity indication" is "communicated sufficiently often to prevent an 
inactivity timeout of said first application being initiated during normal operation of said 
first application by said managing application in response to said timeout window being 
exceeded." Cohen (with Tran) does not suggest such features. As recognized in the 
Rejection page 3, Cohen does not teach a system able "to prevent an inactivity timeout of 
said first application being initiated during normal operation of said first application/" 
Applicant respectfully submits that the Examiner is incorrect in maintaining on page 8 of 
the Rejection that Tran (with Cohen) teaches a system able to ^prevent an inactivity 
timeout of said first application being initiated during normal operation of said first 
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application" by a "managing application" in response to a "timeout window being 
exceeded/' 

Tran, in column 9 lines 14, 23 and lines 42-62 relied on in the Rejection, describes a 
system for searching "its database to find the web page of the network server" or a 
"network's general web site." In the "illustrative example, for IBM organization, LDAP 
begins the search for the userid at the first IBM location in the database (Austin) and 
continues sequentially through the different IBM locations.. if one of the locations is 
unavailable (for example, the network server is down), the process continues to the next 
location after a timeout condition is reached. For illustrative purposes, this timeout 
condition may occur after 5 seconds or after 5 tries to access the server or network at a 
location is unsuccessful The timeout condition is used to prevent the search from stalling 
at an unaccessibie location. A check is made for the occurrence of a timeout so that the 
process continues smoothly" (Tran column 9 lines 43-57). 

The Tran (with Cohen) timeout function is fundamentally different to the claimed 
method and comprises a different function employed in a different manner to achieve a 
different result that addresses a different problem. The re-try or timeout system of Tran, 
relied on in the Rejection, addresses an abnormal condition, specifically, "this timeout 
condition may occur after 5 seconds or after 5 tries to access the server or network at a 
location is unsuccessful" to "prevent the search from stalling at an unaccessibie location" 
(Tran column 9 lines 52-56) and is not related to ''normal operation'' of a "first 
application" ai all. In the Tran system, an LDAP compatible application searches for a 
"web page of the network server" or a "network's general web site" ("LDAP begins the 
search for the userid at the first IBM location in the database (Austin) and continues 
sequentially through the different IBM locations... timeout condition may occur after 5 
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seconds or after 5 tries" by the LDAP application "to access the server or network" (Tran 
column 9 lines 45-55)), Consequently, the timeout condition occurs in response to a 
periodic clock measurement i.e., of "5 seconds" or a re-try count "after 5 tries" by the 
LDAP application and independently of user initiated activity and is NOT an indicator 
of "activity" but merely that a search by an LDAP application has timed out due to an 
abnormal (e.g. an "unaccessible" location) condition. 

The timeout condition in Tran is generated even when there is no user activity in the 
LDAP application. Therefore, the Cohen with Tran system does not suggest a "first 
application" of a "plurality of concurrently operating applications for intermittently 
communicating an activity indication" generated "in response to user action" to "a 
managing application" to "prevent an inactivity timeout" of the "first application being 
initiated during normal operation of said first application". Further, Tran (with Cohen) 
falls to show or suggest generation of an "activity indication notification" in response "to 
user action and being communicated sufficiently often to prevent an inactivity timeout of 
said first application being initiated during normal operation of said first application by 
said managing application in response to said timeout window being exceeded/' Also, since 
the Tran (with Cohen) timeout condition is generated by an application independent of 
user action, the Cohen with Tran system is incapable of "monitoring and controlling a 
duration of a user session," in contrast to the claimed arrangement. 

The re~try or timeout system of Tran (with Cohen), relied on in the Rejection, 
addresses an abnormal condition, specifically, "this timeout condition may occur after 5 
seconds or after 5 tries to access the server or network at a location is unsuccessful" to 
"prevent the search from stalling at an unaccessible location" (Tran column 9 lines 52-56) 
and is not related to "normal operation" of a "first application." In contrast, in the 
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claimed arrangement, a "first application'" of a "plurality of concurrently operating 
applications" intermittently communicates "an activity indication" generated "in response 
to user action" to "prevent an inactivity timeout" of the "first application being initiated" 
during "normal operation of said first application" in response to the "timeout window 
being exceeded." The communicated "activity indication" Is used to identify a "normal" 
condition of user inactivity in employing an application, whereas the Cohen with Tran. 
system identifies a purely abnormal condition comprising a failure circumstance. Further, 
incorporating the re-try timeout mechanism of Tran into the Single Sign On system of 
Cohen, as suggested in the Rejection, results in a system for detecting an abnormal 
condition during user Logon and initiates a timeout "after 5 seconds or after 5 tries" for 
example, when it is "unsuccessful" in accessing a server or network, and thus can only 
detect a failure condition. This combined system is Incapable of preventing "inactivity 
timeout" of a "first application being initiated" in response to user inactivity. 

The re-try timeout mechanism of Cohen with Tran addresses the problem of 
managing an abnormal condition and detecting a failure condition during user Logon by 
initiating a timeout condition "after 5 seconds or after 5 tries" that are "unsuccessful" in 
accessing a server or network, for example, (Tran column 9 lines 52-56) and does not 
recognize, contemplate or address the problems of application inactivity management 
under "normal" operating conditions. Therefore, Cohen with Tran provides no problem 
recognition, motivation, or other reason for incorporating the claimed features. 
Consequently withdrawal of the Rejection of claim 23 under 35 USC 103(a) is respectfully 
requested, 

CLAIM 24 

The method of claim 24 is used "in a system supporting concurrent operation of a 
plurality of network compatible applications" and comprises the activities of "intermittently 
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receiving activity indications from a plurality of concurrently operation applications of a 
particular operating session of a user, an individual activity indication being generated in 
response to user action; updating a single activity status indicator associated with said 
plurality of concurrently operating applications of said particular operating session, in 
response to said received activity indications; comparing said single activity status 
indicator with a time-out threshold value to identify a time-out event indicated by a status 
indicator exceeding said time-out threshold and occurring during normal operation of an 
application; and re-initializing said plurality of concurrently operation applications in 
response to said comparison." Application respectfully submits that these features are 
neither shown nor suggested by Cohen with Tram Independent method claim 24 is 
considered to be patentable for reasons given in connection with claims 1 and 3 0 and for 
additional reasons. 

Claim 24 is also considered to be patentable because Cohen with Tran does not 
show or suggest a method involving "intermittently receiving activity indications from a 
plurality of concurrently operating applications of a particular operating session of a user, 
an individual activity indication being generated in response to user action" and further 
including the activity of "updating a single activity status indicator associated with said 
plurality of concurrently operating applications of said particular operating session, in 
response to said received activity indications". Cohen in column 8 and Figure 5 relied on in 
the Rejection, with Tran, foils to suggest a method involving 'intermittently receiving 
activity indications from a plurality of concurrently operating applications of a particular 
operating session of a user" and "an individual activity indication being generated in 
response to user action" and further including the activity of "updating a single activity 
status indicators associated with said plurality of concurrently operating applications of 
said particular operating session, in response to said received activity indications". Cohen 
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with Tran fails to suggest "comparing said single" user responsive "activity status 
indicators with a time-out threshold value to identify a time-out event indicated by a status 
indicator exceeding said time-out threshold and occurring during normal operation of an 
application; and re-initiaJizing said plurality of concurrently operating applications in 
response to said comparison". Rather, Figure 5 of Cohen, relied on in the rejection, merely 
describes a screen displaying the systems/applications (targets) the user is able to logon to 
and the status of the logon process, namely whether the user is logged in to the target or 
not. There is no indication or even suggestion of activity status indicators, let alone "a 
single activity status indicator with a time-out threshold value to identify a time-out event 
indicated by a status indicator exceeding said time-out threshold and occurring during 
normal operation of an application; and re-initializing said plurality of concurrently 
operating applications in response to said comparison" as recited in the present claimed 
invention. 

Contrary to the assertions in the rejection, Column 8, lines 45-62 of Cohen neither 
discloses nor suggests "updating a single activity status indicators associated with said 
plurality of concurrently operating applications of said particular operating session, in 
response to said received activity indications/' as recited in the present claimed invention. 
Rather, this passage of Cohen (with Tran) merely describes avoiding "target passwords 
being revealed to SSO administrators (or others)'' by encrypting the password field with a 
master key. This makes absolutely no mention or even suggestion of "updating a single 
activity status indicator associated with said plurality of concurrently operating 
applications of said particular operating session, in response to said received activity 
indications" as recited in the present claimed invention. Further, Cohen is concerned with 
providing a mechanism for allowing different passwords for different target systems and 
applications and only requiring the user to remember one password to log into the 
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mechanism. This is wholly unlike the present claimed invention which is concerned with 
monitoring the activity status of concurrently operating applications for time-out events. 
Cohen with Tran fail to disclose or suggest "receiving activity indications.., generated in 
response to user action," "updating a single activity status indicator" and "comparing 
said single activity status indicators with a time-out threshold value to identify a time-out 
event indicated by a status indicator exceeding said time-out threshold and occurring during 
normal operation of an application." 

The re-try timeout mechanism of Cohen with Tran addresses the problem of 
managing an abnormal condition and detecting a failure condition during user Logon by 
initiating a timeout condition "after 5 seconds or after 5 tries" that are "unsuccessful" in 
accessing a server or network, for example (Train column 9, lines 52-56) and does not 
recognize, contemplate or address the problems of application inactivity management 
under "normal" operating conditions. Therefore, Cohen with Tran provides no problem 
recognition motivation, or other reason for incorporating the claimed features. 
Consequently withdrawal of the Rejection of claim 24 under 35 USC 103(a) is respectfully 
requested. 

VIII CONCLUSION 

Cohen with Tran, alone or in combination, neither discloses nor suggests an 
"entitlement processor for enabling user access to a first application of a plurality of 
currently operating applications in response to validation of user identification," as recited 
in the present claimed invention. Furthermore, Cohen with Tran neither discloses nor 
suggests, "a communication processor employed by said first application of said plurality 
of concurrently operating applications for intermittently communicating an activity 
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indication to a managing application within a timeout window, said activity indication 
being generated in response to user action and being communicated sufficiently often to 
prevent an inactivity timeout of said first application being initiated during normal 
operation of said first application by said managing application in response to said timeout 
window being exceeded," as recited in the present claimed invention. 



Accordingly it is respectfully submitted that the rejection of Claims 1- 24 should be 
reversed. 
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APPENDIX I - APPEALED CLAIMS 



1 . (Previously Presented) A system for use in a first application concurrently 
operating together with a plurality of network compatible applications, comprising: 

an entitlement processor for enabling user access to a first application of a 
plurality of concurrently operating applications in response to validation of user 
identification information; and 

a communication processor employed by said first application of said 
plurality of concurrently operating applications for intermittently communicating an 
activity indication to a managing application within a timeout window, said activity 
indication being generated in response to user action and being communicated sufficiently 
often to prevent an inactivity timeout of said first application being initiated during normal 
operation of said first application by said managing application in response to said timeout 
window being exceeded, 

2. (Previously Presented) A system according to claim 1 T wherein 

said intermittently communicated activity indication prevents an inactivity 
timeout of said plurality of concurrently operating applications of a particular user initiated 
session, 

3. (Original) A system according to claim L wherein 

said communication processor stores a plurality of activity indications and 
sends said plurality of activity indications as a batch to said managing application. 

4. (Previously presented) A system according to claim I, wherein 

said normal operation comprises application operation exclusive of 
abnormal operation comprising an application failure condition and 

said user action comprises at least one of, (a) keyboard activity, (b) mouse 
activity, (c) other data entry device activity and (d) another user initiated PC application 
operation activity. 

5. (Previously Presented) A system, according to claim 1, wherein 

said first application and said managing application reside in the same PC 

and 

said activity indication notifies said managing application of activity by said 
first application and includes one or more of, (a) a session identifier for identifying a 
particular user initiated session, (b) a URL to be contacted if said activity notification is not 
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successful, (c) an identification of a type of event preventing said activity notification from 
being successful. 

6. (Original) A system according to claim 1, wherein 

said communication processor intermittently communicates activity 
indications to said managing application using a plurality of different commands including 
an activity notification command and a command involving at least one of, (a) determining 
a user operation session identifier from said managing application and (b) sending a URL 
to said managing application. 

7. (Original) A system according to claim 1, wherein 

said communication processor communicates to said managing application a 
request to receive an. activity indication associated with said first application and 
maintained by said managing application, said activity indication indicating time since the 
last activity update. 

8. (Previously Presented) A system according to claim I, wherein 
individual applications of said plurality of concurrently operating 

applications independently intermittently communicate an activity indication to said 
managing application and 

said communication processor communicates with a browser application 
providing a user interface display permitting user entry of identification information for 
validation by said entitlement processor. 

9. (Original) A system according to claim 1, wherein 

said communication processor communicates a time-out threshold value 
comprising said timeout window to said managing application. 

10. (Previously Presented) A system for use by a managing application 
su PP ortin g concurrent operation of a plurality of Internet compatible applications, 
comprising: 

an input processor for intermittently receiving activity indications from a 
plurality of concurrently operating applications, an individual activity indication being 
generated in response to user action; 

an activity monitor for updating individual activity status indicators, 
corresponding to said plurality of concurrently operating applications, in response to said 
received activity indications; 

a comparator for comparing individual activity status indicators with 
corresponding time-out threshold values to identify an application time-out event indicated 
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by a status indicator exceeding said time-out threshold and occurring during normal 
operation of an application; and 

a communication processor for communicating notice of said application 
time-out event to one of said plurality of concurrently operating applications. 

1 1 . (Previously Presented) A system according to claim 10, wherein 

said activity indications received by said input processor are provided in 
response to a user action and 

said user action comprises at least one of, (a) keyboard activity, (b) mouse 
activity, (c) other data entry device activity and (d) another user initiated PC application 
operation activity. 

12. (Original) A system according to claim 10, wherein 

an activity status indicator comprises a time indication identifying when 
activity of a particular application was last reported, and 

said time-out threshold comprises a predetermined time duration and said 
managing application determines said particular application to be inactive if said time 
indication exceeds said time-out threshold. 

13. (Original) A system according to claim 10, wherein 

said input processor receives activity indications from a plurality of different 
commands including an activity notification command and a command involving at least 
one of, (a) determining a user operation session identifier from said managing application 
and (b) sending a URL to said managing application, 

14. (Original) A system according to claim 10, wherein 

said communication processor communicates notice of said application time- 
out event to applications of said plurality of concurrently operating applications that have 
previously requested a notification of session termination, 

15. (Original) A system according to claim 1.0, wherein 

said communication processor communicates notice of said application time- 
out event in response to at least one condition of, (a) a received command requesting 
notification and (b) a received communication from an application session having 
previously produced a time-out event and (c) automatically upon generation of said time- 
out event. 

16. (Original) A system according to claim 10, wherein 

said activity indication includes one or more of, (a) an identification of a 
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particular user initiated session, (b) a URL to be contacted if said activity notification is not 
successful, (c) an identification of a type of event preventing said activity notification from 
being successful. 

17. (Original) A system according to claim 10, wherein 

said corresponding time-out threshold values comprise a common timeout 
period for said plurality of concurrently operating applications, 

18, (Original) A system according to claim 10, wherein 

said comparator uses a predetermined default value for said time-out 
threshold values. 



19. (Previously presented) A system supporting concurrent operation of a 
plurality of Internet compatible applications, comprising: 

a browser application providing a user interface display permitting user 
entry of identification information and commands for a plurality of Internet compatible 
applications; and 

a managing application for receiving activity indications from a plurality of 
concurrently operating applications, an individual activity indication being generated in 
response to user action, said plurality of concurrently operating applications being initiated 
by user commands via said browser user interface, said received activity indications being 
provided by individual applications sufficiently frequently to prevent an inactivity timeout 
of said individual applications and during normal operation of an individual application. 

20. (Original) A system according to claim 19, wherein 

said activity indication notification includes one or more of, (a) an 
identification of a particular user initiated session, (b) a URL to be contacted if said activity 
notification is not successful, (c) an identification of a type of event preventing said activity 
notification from being successful, 

21. (Original) A system according to claim 19, wherein 

a common timeout period is used as said inactivity timeout for said plurality 
of concurrently operating applications. 

22. (Previously presented) In a system supporting concurrent operation of a 
plurality of network compatible applications, a method comprising the activities of: 

intermittently receiving activity indications from a plurality of concurrently 
operating applications, an individual activity indication being generated in response to user 
action; 
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updating individual activity status indicators, corresponding to said plurality 
of concurrently operating applications, in response to said received activity indications; 

comparing individual activity status indicators with corresponding time-out 
threshold values to identify an application time-out event indicated by a status indicator 
exceeding said time-out threshold arid occurring during normal operation of an application; 
and 

communicating notice of said application time-out event to one of said 
plurality of concurrently operating applications. 

23. (Previously presented) A method employed by a first application 
operating in a system supporting concurrent operation of a plurality of network compatible 
applications, said method comprising the activities of: 

enabling user access to a first application of a plurality of concurrently 
operating applications in response to validation of user identification information; and 

supporting intermittent communication by said first application of an activity 
indication to a managing application within a timeout window, said activity indication 
notification being generated in response to user action and being communicated sufficiently 
often to prevent an inactivity timeout of said first application being initiated during normal 
operation of said first application by said managing application in response to said timeout 
window being exceeded. 

24. (Previously presented) In a system supporting concurrent operation of a 
plurality of network compatible applications, a method comprising the activities of: 

intermittently receiving activity indications from a plurality of concurrently 
operating applications of a particular operating session of a user, an individual activity 
indication being generated in response to user action; 

updating a single activity status indicator associated with said plurality of 
concurrently operating applications of said particular operating session, in response to said 
received activity indications; 

comparing said single activity status indicator with a time-out threshold 
value to identify a time-out. event indicated by a status indicator exceeding said time-out 
threshold and occurring during normal operation of an application; and 

re-initializing said plurality of concurrently operating applications in 

response to said comparison. 
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APPENDIX II - EVIDENCE 

Applicant does not rely on any additional evidence other than the arguments 
submitted hereinabove. 
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APPENDIX III - RELATED PROCEEDINGS 

Applicant respectfully submits that there are no proceedings related to this appeal in 
which any decisions were rendered, 
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